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[57] ABSTRACT 

A data retrieval and acquisition system having a wireless 
handheld interface for data entry by the user. The system 
includes a communication server for communicating, such 
as through IR signals, with the handheld interfaces. The 
communications server communicates with multiple com- 
mand servers and with a master server and/or other com- 
munication servers through a communications bus. The 
handheld interface includes touch screen which is operated 
through an event driven architecture. The user is allowed to 
enter data through virtual rolling keys, a scroll bar, virtual 
key pad, bar code reader, and the like. The system mini- 
mized the transmission time by minimizing the necessary 
information transmitted and by synchronizing the operation 
of the handheld interfaces with the corresponding commu- 
nications server. The communications server transmits infor- 
mation to the handheld through a first unique protocal and to 
the command server through a second unique protocal. Data 
transmission is further reduces by using shorthand command 
codes for constants, such as for commands, user names, and 
the like. 
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DATA ACQUISITION AND RETRIEVAL 
SYSTEM WITH WIRELESS HANDHELD 
USER INTERFACE 

BACKGROUND OF THE INVENTION 5 

1. Field of the Invention 

The present invention relates in general to a system for 
data acquisition and retrieval through the use of an user 
interface remotely located from the control system. 

2. Description of the Related Art 10 
Today, most commercial businesses require field 

employees, such as at points of sale, to fill out paper forms 
with data sets concerning individual customers or products 
sold/manufactured. These reports are then collected, 
compiled, and assimilated at a central location and filed for 
future access. Most modern businesses require this infor- 
mation to be continuously updated and that the field per- 
sonnel be afforded quick access thereto in order to reduce 
business costs, improve efficiency, increase accuracy, and 2Q 
the like. Heretofore, data sets concerning matters, such as 
customer or product information have been primarily com- 
piled through paper forms completed by field personnel and 
later possibly entered into some form of central database. 

In the healthcare field, hospitals utilize a significant 25 
amount of data retrieval and acquisition, with respect to 
patient information. All data sets containing patient infor- 
mation (data field), such as patient name (a data set header), 
date of birth, place of business, address, phone numbers, 
language, billing account number, social security number, 30 
drivers license number, and the like were written on paper 
forms and maintained in a paper file, and optionally entered 
by the hospital staff into a common database. Thereafter, the 
patient information was supplemented with information 
pertaining to their health condition, such as vital signs, fluid 35 
intake, fluid output and the like, which were written on 
different paper forms by a nurse and later keyed into this 
common database. Similarly, when patients undergo testing, 
the test results were manually keyed into the common 
database and/or written on forms stored in the patient's 40 
paper file. 

An alternative example lies in the insurance industry in 
which field claims adjusters travel to the site of an insurance 
claim and evaluate the damaged property. These adjustors 
fill out multiple forms identifying the damage and the 45 
insured person's general information. For instance, in an 
automotive accident the claims adjustor must describe each 
problem with the insured car, such as dents, scratches, and 
the like. These forms are later processed manually or keyed 
into a common database, after which, the claimant ulti- 50 
mately is paid. 

A substantial amount of data acquisition and retrieval is 
also utilized in factory environments. During the course of 
manufacturing various products, floor workers and quality 
review must complete multiple forms concerning a given 55 
production unit. 

However, every business requiring significant amounts of 
data acquisition and retrieval in its day-to-day business 
encounter similar problems. First and foremost, a significant 
amount of the field operative's time is required in filling out 60 
the corresponding paperwork, in which the potential for user 
error exists. Also, in systems using paper forms, the infor- 
mation must be ultimately transferred to an electronic 
database, which provides a second opportunity for user 
error. Clearly, it would be advantageous to reduce the 65 
number of user entries, thereby reducing the likelihood of 
error. 
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Further, in many markets, field personnel at one location 
typically require information quickly from another field 
location. For instance, in a hospital environment, a doctor 
within the general ward may require immediate information 
concerning a patient from the radiology department. 
However, the process under which the information is written 
down and carried between departments is very slow. 
Similarly, doctors and nurses require immediate and accu- 
rate knowledge of specific procedures to be followed with 
regard to particular patients. Past systems for maintaining 
individual patient procedures have proven ineffective. 

Moreover, one office within a business will typically 
require information from another office which must be hand 
carried or which is unavailable after the closing hours of the 
second office. For instance, hospitals require lab testing 
results be hand -carried to doctors who may be waiting for 
such results during the course of surgery. Also, typically 
doctors require clinical data after the clinics have closed. 

The need remains in this field for an improved data 
acquisition and retrieval system to address the problems and 
drawbacks heretofore experienced. The primary objective of 
this invention is to meet this need. 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a data 
acquisition and retrieval system which allows users imme- 
diate real time access to all existing customer/product infor- 
mation. 

It is an object of the present invention to provide a data 
acquisition and retrieval system which affords users access 
to wireless remote data terminals. 

It is an object of the present invention to minimize the 
data retrieval time by reducing the necessary information 
transmitted between handheld units and the corresponding 
communications server. 

It is another object of the present invention to minimize 
the data necessary for transmission by synchronizing opera- 
tion within each handheld unit and a corresponding com- 
munications server, such synchronization including the 
minimization of header information for each transmission 
and the transmission of a command case code used directly 
by the command server to access a designated database. 

It is another object of the present invention to provide a 
user interface which minimizes user error. 

It is another object of the present invention to provide a 
user interface which utilizes an event driven architecture to 
allow data entry through a touch pad. 

It is another object of the present invention to provide an 
user interface which is easily operated by using a touch pad 
which presents a scroll bar, rolling keys and icons for data 
entry. 

It is another object of the present invention is to provide 
an user interface which allows for the scanning of bar codes 
to identify particular customers or products. 

These and further objects will become more apparent 
from the drawings and detailed description hereafter. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The objects and features of the invention noted above are 
explained in more detail with reference to the drawings, in 
which like reference numerals denote like elements, and in 
which: 

FIG. 1 is a block diagram of an overview of a data 
acquisition and retrieval system according to the present 
invention; 
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FIG. 2 illustrates a block diagram of a handheld interface servers 14 may implement any conventionally known 10 

according to the present invention; management system, such as Pro-Tree (version 2.0), SQL or 

FIGS. 3(a)-3(</) illustrate exemplary display screens Paradox. The communications server 12 communicates with 

shown on the handheld interface according to the present cacn handheld interface 8 through a unique communications 

invention- 5 protocol (hereafter referred to as the Handheld-Server 

FIG. ^illustrates the main processing loop by which the Protocol). The communications server 12 communicates 

handheld interface monitors and responds to events selected ™ th the co " d " « hrou f . a ™ique protocol 

bv the user- (hereafter referred to as the Message List Protocol). 

y . ' . As explained below, the communications server 12 syn- 

FIG. 5 illustrates the processing sequence of the handheld JQ chronizcs its opcra ti OD s with those of the handheld inter- 
interface while displaying a patient information screen; faceg g tQ mimmize me excess data necesS ary for each 

FIG. 6 illustrates the processing sequence of the handheld transmission therebetween. The communications server 12 

interface to initiate the patient information screen; and interface 8 also utilize shorthand code values to identify 

FIGS. l{a)-l(b) illustrate the processing sequence of the constantly transmitted information, such as commands, user 

handheld interface while displaying a patient input screen; is IDs, database IDs, and the like. By synchronizing operation 

FIG. 8 illustrates the processing sequence of the handheld of lhe handheld interface 8 and the corresponding commu- 

interface to initiate the patient input screen; nications server 12, the instant system is able to avoid the 

FIG. 9 illustrates the data structure of the packets trans- ™f «° ^ansmit the user ID, time, date, authorization code, 

mitted between the handheld interface and the communica- an ^ thc llkc d ™»* ^ U ~ sl0n A , 

tions server* 20 During operation, the user enters data at the handheld 

' . „ , interface 8, the data is transmitted to the communications 

FIG. 10 illustrates the processing sequence undergone by seryer u and stored intemally ^ihin tne database 16 . Data 

the handheld interface to write data packets to the comrnu- may al&0 be cntercd direct]y ink) thc communications ^rvcr 

nications server; 12 . Similarly, the user may request data previously 

FIG. 11 illustrates the processing sequence by which the 2 s submitted, in which case the communications server 12 
communication server reads packets transmitted from the accesses the corresponding database 16, through the corn- 
handheld interface; mand server 14, and transmits the necessary desired infor- 

FIG. 12 illustrates the processing sequence by which the mation to the requesting handheld interface 8. Throughout 

communication server parses through a short header struc- operation, a backup copy may be maintained within the 

ture within an incoming packet to build the input buffer; 30 master server 2 for every remote database 16. Additionally, 

FIG. 13 illustrates the processing sequence by which the ^e user may request, via the handheld interface 8, data 

communication server parses through a long header struc- stored within a remote input unit 4 other than the data in the 

ture within an incoming packet to build the input buffer; databases directly connected to the receiving communica- 

FIG. 14 illustrates the processing QUEUE sequence to tions * r T cr 12 In SUC \ * circ » mstanc f ; < he corresponding 

move completed messages to the processing QUEUE. 35 commumca ions ^ 

r • . handheld interface 8, determine that the desired information 

FIG. 15 illustrates the processing sequence by which the ^ stofed a remote database and fequest mch infor . 

communication server generates the processing queue; m ^ QQ thrQugh the communications bus 6 from the com- 

FIG. 16 illustrates a block diagram of the RAM section of munications server 12 containing the corresponding data- 

the handheld interface; 40 base. Thus, the communications bus 6 also allows data to be 

FIG, 17 illustrates a block diagram of the communications transmitted between communications servers 12 and 

server; between handheld interfaces 8 (such as when one doctor is 

FIG. 18 illustrates an alternative data entry display for the requesting information from another doctor), 

handheld interface; and B Y wa y of example only, the instant acquisition/retrieval 

FIG. 19 illustrates the processing sequence of the com- 45 ^ slem 1 ma y bc ui *™i ^ a u hca u lth ^ ^cihty wherein 

mand server to process and transmit message lists. doct ° rs > aracs, and staff utilize the handheld interfaces 8 to 

record and obtain patient information. These persons may be 

DETAILED DESCRIPTION OF THE assigned different privileges which would allow varying 

INVENTION levels of access to data. In this environment, each commu- 

Overview 50 nications server may be located within a different ward or 

FIG. 1 illustrates a data retrieval/acquisition system testing laboratory. Thus, a doctor in a general ward may need 

according to the present invention generally illustrated by to send a message to, or obtain information from, a doctor 

the reference numeral 1. The instant system 1 includes a or nurse in radiology. To do so, the doctor would transmit a 

master server 2 which communicates with multiple remote request through the handheld interface 8, with the request 

input units 4 through a communications bus 6. Each input 55 being received and decoded in the general ward's comrnu - 

unit 4 includes a communications server 12 directly con- nications server 12. The source/receiving communications 

nected to a command server 14 and data bases 16. Each server determines the appropriate destination communica- 

remote communications server 12 interactively communi- tions server that corresponds to the destination handheld 

cates with one or more handheld user interfaces 8 while interface, into which the destination doctor or nurse has 

located within a predefined region 5 proximate thereto. This 60 signed on. The desired message is transmitted to the radi- 

interactive communication is conducted through a wireless ology server, and to the corresponding handheld interface 

dedicated communications channel, such as upon an infrared which queries the user through audio, video, or vibrating 

carrier signal. means. In a similar manner, the user within radiology may 

The communications server 12 controls all interaction transmit a response through the corresponding radiology and 

between the handheld interfaces 8, the command servers 14, 65 general ward communications servers 12 to the requesting 

and the communications bus 6. The command servers 14 doctor's handheld interface 8. Also, lab data may be quickly 

control direct access to the databases 16. The command transmitted to a surgeon during an operation. 
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The instant acquisition/retrieval system 1 also allows 
doctors, nurses, and staff members immediate access to 
clinical data, even after clinic hours are closed. To do so, the 
user merely enters a request through his/her handheld inter- 
face 8, which is transmitted through the corresponding 5 
communications server 12 to the clinical communication's 
server 12. The necessary clinical data is obtained from the 
clinical database and returned along the communications bus 
6. By way of example, the data acquisition/retrieval system 
1 of the healthcare facility may be connected to similar 10 
systems via an ethernet connected between the master 
servers 2. 

The handheld interfaces 8 are used to enter all patient 
information such as personal information upon admittance, 
past medical histories, vital statistics throughout their stay in is 
the hospital, and the like. For instance, these vital statistics 
may include systolic, diastolic, pulse, temperature, and 
respiratory information. Similarly, the handheld interface 8 
may be used to enter information concerning the patient's 
fluid intake and output. 20 

As will be explained below, the instant data acquisition/ 
retrieval system 1 also allows a user to carry a handheld 
interface 8 between regions (see the dashed line 5 in FIG. 1) 
dedicated to each communications server 12. Optionally, 
when this occurs, the handheld interface 23 is considered to 25 
have signed off with the old communications server (as 
illustrated by the dashed line 22). Thereafter, the handheld 
interface 23 must be signed onto the new communications 
server (as illustrated by the line 24) before it may be used for 
data entry. 

The manner by which these objects and functions is 
achieved will become clear in connection with the following 
explanation of each module of the present invention. 
Handheld Interface 

FIG. 2 generally illustrates a block diagram of a handheld 
interface 8 having a display screen 30 which may be 
back-illuminated and which is controlled by a CPU 32 to 
display desired information thereon. The display screen 30 
also functions as a touch pad and is sensitive to user contact. 
When contacted, the display screen 30 outputs a signal to the 
CPU 32 identifying the exact location of the contact there- 
with. The handheld interface 8 further includes a memory 
module 34 which stores software to control processing of the 
CPU 32 and which temporarily stores data received from, 
and transmitted to, the corresponding communications 
server 12. The CPU 32 controls an IR interface 36 to control 
data transmissions to and from the communications server 
12, A bar code reader 37 is included to allow the user to enter 
customer or product information from a bar code, such as 
customer/patient ID and the like. 

As explained below, the handheld interface 8 operates as 
an "event driven" device wherein the touch screen 30 is 
drawn to display a desired arrangement of virtual regions. 
Each region is assigned a unique identifier. The handheld 
interface 8 recognizes each contact by a user as an event. 
The contact/event is recognized with respect to the corre- 
spondingly denned region and the region identifier is 
returned. Thereafter, the CPU 32 identifies the necessary 
course of action based upon this identifier. 

As illustrated in FIG. 3, during operation the CPU 32 may 60 
display a variety of menus, graphs, and the like upon the 
touch screen 30. Within each display, the CPU 32 defines 
virtual regions which correspond to predefined processing 
sequences. The user initiates a desired event sequence by 
contacting the preferred region corresponding to the event. 65 
To facilitate the user interaction therewith, the CPU 32 
provides multiple manners in which the user may enter and 
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retrieve data. As illustrated in FIG. 3(a), the CPU 32 draws 
a main menu 38 on the screen 30 and defines multiple menu 
selections 40 therein (see the flowchart of FIG. 10). Each 
menu selection 40 overlays and corresponds to a virtual 
event region 42 corresponding to a different event/case. 
Every screen 30 is displayed with an escape key 43 which 
allows the user to escape back to a previous function/screen 
or back to the main menu. 

When implemented in a healthcare application, as illus- 
trated in FIGS. 3a-3d, when the user selects a vitals event 
region 44, the CPU 32 recognizes it as such and processes 
a corresponding event sequence (see FIG. 13). 

As illustrated in FIG. 3c, the vitals input screen 60 (also 
referred to as the data I/O screen) displays current patient 
information in the patient field 62, such as the patient's 
name, social security number, status, and the date upon 
which the vitals were last updated. The vitals input screen 60 
illustrates the last current vitals (data sets) as shown in the 
systolic field 46, diastolic field 48, pulse field 50, tempera- 
ture field 52, and respiratory field 54 (collectively referred to 
as data fields). The touch screen 30 allows the user to 
activate a desired vital sign field by selecting a correspond- 
ing icon 46, 48, 50, 52, and 54, respectively. Located 
immediately above each icon is the current value for the 
corresponding vitals field. This current value is also dis- 
played within three rolling keys along side of the icon (the 
rolling keys are designated by the reference numeral 56). 
The patient's systolic vital sign field is active in FIG. 3c, as 
evidenced by the inverted rolling keys 56. Proximate the 
rolling keys 56 is a scroll bar 58 for illustrating in a bar 
format the current value of the active vital sign field (i.e., 
systolic) which is inverted to the current level (130). 

To enter new patient vitals, the user may do so in multiple 
ways. First, the user may update the patient's systolic vitals 
by consecutively contacting each rolling key 56 to be 
incremented. Each rolling key continuously increments, 
such as from 0 to 9 and then back to 0. Alternatively, the user 
may enter patient vitals information by contacting the scroll 
bar 58 at the desired position. In accordance with the 
flowchart of FIG. 13, when the user contacts the scroll bar 
58, the bar is updated to reflect the newly entered value. If 
the user drags his/her finger along the scroll bar 58, the CPU 
32 will continuously update the level thereof to reflect this 
movement of the finger. The CPU 32 updates the corre- 
sponding rolling keys 56 for the active field (i.e., the systolic 
field as illustrated in FIG. 3(c)). The user may drag his/her 
finger across the scroll bar 58 until the desired value is 
displayed in the rolling keys 58, at which time the user 
releases the scroll bar. The user may activate a different vital 
sign field (i.e., change the mode) by selecting the corre- 
sponding icon (46, 48, 50, 52, and 54). 

The vitals input screen 60 further includes change func- 
tion keys 64 which afford the user's direct access to displays, 
graphs, screens and the transmit function. More specifically, 
the vitals input screen 60 allows the user direct access to the 
fluids input screen (not shown) for the current patient by 
pressing the fluids function button 66. Alternatively, the user 
may view the selected vital sign field (e.g., systolic field) in 
a graph format by selecting the view graph button 68. The 
vitals input screen 60 further includes a transmit information 
button 70 which the user selects once a patient's new vital 
information has been entered. When the transmit button 70 
has been pressed, the CPU 32 transmits the updated patient 
information to the communications server 12 in a format 
described below. 

FIG. 3(b) illustrates a graph corresponding to the present 
patient's systolic vitals which is displayed when the view 
graph button 68 is selected. 
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FIG. 3(d) illustrates a patient inquiry screen 74 (also 
referred to as the data set inquiry screen) selected from the 
main menu 38. The patient inquiry screen 74 displays a 
scrolling text window 78 which exhibits the currently 
selected patient* s name (data set header) and those names 
alphabetically proximate thereto. Along one side of the 
-scroll text window 78 is positioned a scrolling bar 80 which 
includes an identifier 82 designating the position of the 
currently selected patient's name within a master alphabeti- 
cal list. The user may scroll through the patient list by 
contacting the scrolling bar 80 at a desired location therea- 
long. The top and bottom of the scrolling bar 80 corresponds 
to the beginning and end, respectively, of the list of patient 
names stored within the handheld interface 8. 

The patient inquiry screen 74 also includes a virtual 
keypad 76 which allows the user to enter the name of a 
desired patient. As the user selects each letter of the desired 
patient's name, the CPU 34 automatically performs a search 
upon the entered letters and updates the scroll text window 
78 correspondingly. As the user enters additional letters, the 
CPU 32 concatenates these letters to the end of the search 
string it uses and again updates the scrolling text window 78. 
The patient inquiry screen 74 also includes function buttons 
64 along a bottom thereof to allow the user to automatically 
jump to an alternative screen. A scan button 77 is included 25 
to allow the user to read bar code data from a patient's wrist 
band, such as patient ID. 

FIG. 18 illustrates an alternative scroll bar implementa- 
tion which may be used to allow the user to enter alphanu- 
meric information. For instance, the CPU 32 may control the 30 
display screen 30 to illustrate a display field 90 and one or 
more scroll bars 92. The scroll bar 92 may be defined such 
that one end corresponds to the letter A while the opposite 
end corresponds to the letter Z. The CPU 32 would define 
multiple regions along the length of the scroll bar 92, each 
region corresponding to one letter of the alphabet. When the 
user contacts the scroll bar 92, a letter corresponding to the 
touched region is displayed in a first location 94 of the 
display field 90 
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transmits a request to the communications server 12 for 
patient information, the CPU 32 redefines the current data 
structure within the working space 102 to correspond to the 
expected format of the return data from the communications 
server 12. 

By way of example only, when the CPU 32 requests 
patient vitals, it expects the returned data to include, in a 
preset order, the patient's social security number, date on 
which the patient vitals were last updated, and the most 
recent systolic, diastolic, pulse, temperature and respiratory 
values. The CPU 32 sets up fields within the working space 
202 for each of these values. When the returned data is 
received, the CPU 32 parses through the returned packet and 
assigns bytes therefrom to the desired field in the working 
space 202. 

The RAM 35 further includes a temporary buffer for 
storing incoming and outgoing packets of information which 
are to be transmitted to and which are received from the 
communication server 12. The CPU 32 moves data from the 
RAM 35 into the temporary buffer 204 immediately before 
transmitting this information and adds a packet header 206 
thereto. 

FIGS, 4-8 illustrate the processing sequence by which the 
CPU 32 controls the main menu, vital sign patient/data set 
input screen and the patient information screen (FIGS. 

Generally, during operation the CPU 32 loops through one 
of two primary case/event handling loops (FIG. 4). The first 
case/event loop operates to draw the main menu (FIG. 3a) 
and to handle events chosen from the main menu. When an 
event occurs which corresponds to a defined key region 
within the main menu, a corresponding event identifier 
returned as the calling identifier. A return code is set equal 
to this calling identifier and the return code is checked 
against a predefined value (0). If the return code is non-zero, 
processing flow enters the second primary loop to call the 
corresponding event handling function. The second primary 
loop corresponds to processing in which a menu other than 
the main menu is displayed (FIGS. 3b-3d). During this 
second loop, a code which identifies the next function to be 



As the user drags his/her finger along the scroll bar, the 40 performed is continuously checked. When the code equals 



letter displayed within the first location 94 will vary corre 
sponding to the currently selected region. Once the user 
removes his/her finger from the scroll bar 92, the last 
identified region is designated as the correct letter and 
entered in the first location 94 of the display. When the user 
again contacts the scroll bar 92, the CPU 32 operates to 
display a corresponding letter in the second field location 96 
of the display field 90. 

If it is desirable to enter numerals within the display field 
90, the CPU 32 may also draw a second scroll bar 98 upon 
the display screen 30. The first end of the second scroll bar 
would represent a 0 while the second end of the scroll bar 98 
would represent a 9. The user would enter numerals in the 
display fields 90 in the same manner as discussed above with 
respect to letters. Optionally, a single scroll bar may be 
provided for letters and numerals with function buttons 100 
and 101 being used to assign letters or numerals to the scroll 
bar. 

FIG. 15 illustrates the RAM section 35 of the memory 
within the handheld interface 8. The RAM memory 35 60 
includes a patient information section 200 for storing a list 
of patient names and (data set headers) patient identifiers 
(data set identifiers) associated with the present user of the 
handheld interface 8. The RAM memory 35 also includes a 
working space 202 for storing all other information entered 
by the user and transmitted between the handheld interface 
8 and the communications server 12. Each time the CPU 32 
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zero, processing returns to the main loop. When the code is 
a nonzero value, the corresponding function is called. Once 
each function is completed it returns a code identifying the 
next function to be performed by the user. This configuration 
reduces the memory requirements by reducing the levels of 
functions to be called, thereby reducing the necessary stack 
space. 

FIG. 4 generally illustrates the processing undergone by 
the handheld interface 8 when the user initiates the first 
session (i.e., when the user first logs in). When a session is 
initiated the handheld unit prompts the user for the user's ID 
and password (step 1602). Next, a packet is constructed in 
the temporary buffer 204 which contains a long header 206 
structure and having a data section including the user ID and 
password (step 1604). This packet is transmitted (step 1606) 
and a validation code therefor is waited upon. If the vali- 
dation code is not received (step 1608) processing returns to 
step 1602 in which the user is reprompted for the ID and 
password. If a validation code is received, processing con- 
tinues to step 1610 in which a return code is set to indicate 
that processing should move to the patient inquiry module. 
Thereafter, the return code is tested to determine whether it 
equals zero (step 1623). If the return code equals zero, 
processing returns to step 1614 in which the main menu is 
redrawn. 

After this initial login sequence is completed, flow enters 
the main event handling loops. First, a main menu is drawn 
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and key regions therein are defined in steps 1612 and 1614, 
after which the system waits for an event to occur (step 
1616). Once an event occurs, it is determined whether the 
event is within a defined menu region 42 (step 1618) (i.e., 
whether the use has touched the display screen 30 at a 
location corresponding to a menu selection 40). If not, 
processing loops back to wait for the next event. If so, an 
event identifier is obtained for the key region in which the 
event occurred (step 1620). Next, an event handling function 
corresponding to the event identifier is called (step 1622). 
Thereafter, processing waits for a call identifier returned 
from the called event handling function. A return code is set 
equal to the call identifier (step 1623) and the return code is 
tested in step 1624 and if zero, processing returns to the 
initial step 1612 to redefine and redraw the main menu. If the 
return code does not equal zero, the process determines that 
the user has selected another function besides displaying the 
main menu. Thus, the event handling function correspond- 
ing to the non-zero return code is called (step 1626). 
Thereafter, the main event handling loop waits for the called 
function to return a call identifier which is tested in step 
1624. 

FIGS. 5 and 6 illustrate the process undergone when the 
patient information screen 74 is selected to be displayed 
(such as during the wake up function or when called by the 
user). First, an initialization routine is called in step 1700 
(steps 1710-1720 in FIG. 6). This initializing process begins 
by determining whether the handheld interface 8 includes a 
list of patient names (data set headers) and IDs (step 1710). 
If this list does not exist (such as when the handheld 
interface has initially been woken up), the unit constructs 
and transmits a packet to the communications server 12 
requesting the patient list associated with the currently 
signed-in user (step 1712). The communications server 12 
receives this packet, identifies the user ID, and requests the 
appropriate information from the command server 14. 
Thereafter, the appropriate database 16 is read and the 
patient list for the user is transmitted back to the handheld 
interface 8. After the interface 8 sets up the data structure in 
the patient memory 200 for the patient list (step 1714), it 
waits for the returned patient list (step 1716). Once the 
patient list (name and ID) is received, it is stored in the 
patient memory 200. 

The handheld interface 8 may not include sufficient 
display space in the scrolling text window 78 to show an 
entire patient's name. Thus, the patient memory section 200 
will only include sufficient memory to store the maximum 
number of characters which may be displayed for a single 
patient name upon the screen. Once the patient list is stored, 
the patient screen format is displayed (step 1718) as illus- 
trated in FIG. 3d. Next, the patient names are displayed in 
the scrolling text window 78 (step 1720) (FIG. 3d). When 
the patient list is too long to be completely displayed within 
the scrolling text window 78, a default portion thereof is 
displayed. Next, the system waits for an event (step 1722, in 
FIG. 6) and when one occurs, an event identifier is assigned 
thereto. 

The event identifier is passed to a case/event statement 
which includes every possible valid value for the event 
identifier. By way of illustration, processing will continue 
along one of six possible processing paths to blocks 1724, 
1726, 1728, 1730, 1750 or 1756, depending upon which 
event occurred. When event 1724 occurs (i.e., the user 
presses the escape icon), the system returns a zero calling 
identifier to the main loop (thereby indicating that no new 
event handling function has been selected). If the event 
indicates that the user has touched the scrolling bar 80, 
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processing flows to box 1726 in which the system deter- 
mines the exact location of the event (step 1732). This 
location is correlated with a pointer that is used as an index 
into the patient list to identify the new patient to be displayed 

5 in the scrolling text window 78. Once the event location is 
determined, the pointer into the patient list is updated and 
the scrolling text window 78 is redrawn to display the name 
of the selected patient and a limited number of patient names 
surrounding the selected name (step 1734). 

Next, the scrolling bar 80 is updated to move the identifier 
82 to a new position identifying the relative location of the 
indexed patient within the overall patient list (step 1736). 
Thus, if the first patient is selected, the identifier 82 is 
redrawn at the top of the scrolling bar 80, and if the last 
patient is selected, the identifier 82 is drawn at the bottom of 

15 the scrolling bar 80. If the event is identified as occurring 
within the scrolling text window 78, processing flows to step 
1728. Specifically, the location of the event is again identi- 
fied (step 1738) relative to the names currently displayed. 
The name closest to the event is identified as the selected 

20 patient. Thereafter, the pointer into the patient list is updated 
to index the newly selected patient name (step 1740). This 
name is displayed in the center of the scrolling text window 
and, optionally, may be inverted in color (step 1740). The 
identifier 82 within the scrolling bar 80 is also redrawn to 

25 properly identify the new position of the selected patient 
within the patient list (step 1740). 

If the keypad 76 is touched, processing flows to block 
1730, at which the letter is identified which corresponds to 
the region touched (step 1742). This selected letter is added 

30 to a temporary patient searching string within the work 
space memory 102 (step 1744). This letter is added to a 
search string (which is empty until the first letter is selected). 
Thereafter, the processor conducts a search based upon the 
search string into the patient list to identify the name most 

35 closely corresponding to the letters) selected from the 
virtual keypad 76 (step 1746). If a search string exists (i.e., 
the user has already entered some letters) the newly selected 
letter is concatenated onto the search string and a new search 
is conducted upon the text strings within the patient fist to 

40 find the first text string which is greater in alphabetic value 
than (i.e., closest to) the search string. The pointer is set to 
the closest patient name and the scrolling text window 78 
and the scrolling bar 80 are updated (steps 1746 and 1748). 
If the user wishes to delete a letter from the search string, 

45 he/she simply pressing the delete region key. 

If the user selects the scan region 77, processing flow 
moves to block 1750. The bar code scanner is read to obtain 
the bar code scanned by the user (step 1752) (this bar code 
may appear on a patient's wrist band and the like). The bar 

50 code includes the patient ID, which is used to find the patient 
name within the patient list (step 1754). Next, the pointer 
into the patient list is updated (step 1756) and the scrolling 
text window 78 and scrolling bar 80 are redrawn (step 1758). 
Once the user has selected a desired patient, the user may 

55 escape from the patient inquiry screen by pressing the 
escape icon 43 in the upper left comer or by selecting one 
of the function 64 buttons at the bottom of the screen (step 
1760). As illustrated in FIG. 3d, the user may escape to the 
main menu, review a patient's information complete record 

60 or review the patient's vitals. If the user presses one of the 
change function buttons 64 at the bottom of the screen, the 
corresponding event identifier is evaluated to determine 
which function key the user has selected (step 1762) and the 
corresponding return code is returned to the main processing 

65 loop in FIG, 16 (step 1764). 

FIGS. 7a, lb and 8 illustrate the processing sequence 
undergone by the handheld interface 8 when the vitals/data 
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input/output handling function is chosen (i.e., when a user 
desires to enter patient vitals). First, the display screen is 
cleared (step 1800) and the vitals (data I/O) format is drawn 
upon the screen (step 1802). Similarly, the key regions are 
defined which correspond to each even identifier. Next, it is 5 
determined whether the workspace memory contains vitals 
for a selected patient (step 1804). If not, the processor 
constructs and transmits a packet (step 1806) requesting 
patient vitals. Thereafter, the workspace memory 202 is set 
up in the data structure corresponding to patient vitals (step 10 
1808). Thereafter, the handheld interface waits for the 
returned patient vitals, receives these vitals in one or more 
packets and disassembles the packets and stores the patient 
vitals in the workspace (step 1810). Next, the processor 
draws the patient vitals onto the screen (step 1812) and sets 15 
the default mode to a predetermined field (e.g., systolic 
field). The vitals for the default field are drawn into the scroll 
bar (step 1814) and the default rolling keys 56 correspond- 
ing to the default field are inverted. Thereafter, the handheld 
interface waits for an event to occur (step 1816 in FIG. la) 20 
and when it occurs, identifies the event number correspond- 
ing thereto. 

Processing flows along one of six paths depending upon 
which event number is identified. While each field upon the 
vitals screen corresponds to a separate event number, the 25 
events as displayed in FIG. 8 may be grouped into six 
general categories, namely, touching a roll key, touching the 
icon, touching the scroll bar, touching the patient's general 
information, touching the escape key, and touching the 
change screen buttons (blocks 1818, 1830, 1840, 1852, 1858 30 
and 1864). Once the event number is identified as corre- 
sponding to a rolling key 56, it is determined whether the 
touched rolling keys are active (step 1819). If not active, 
processing returns to step 1816. If active, a pointer is 
determined which identifies the field within the workspace 35 
memory 202 which corresponds to the specific roll key/vital 
sign selected (step 1820). 

Next, the data value identified by the pointer into the 
workspace is incremented by a 1, 10, 100, etc. depending 
upon the rolling key which was touched (step 1822). Thus, 40 
referring to FIG. 3c, if the user presses the center rolling key 
corresponding to the systolic field, the systolic data value 
within the workspace memory will be incremented by 10. 
Similarly, if the diastolic field is selected and the user 
presses the leftmost rolling key therein, the processor will 45 
increment the diastolic data value within the workspace 
memory by 100. Next, it is determined whether or not the 
incremented value has created an overflow and if so, the 
incremented digit is rolled -over (step 1824). This rollover 
function is performed to rotate a rolling key having a current 50 
value of 9 to a new value of 0. 

Thus, if the user selects the pulse vital and contacts the 
"Is" rolling key (which has a present value of 9), the 
processor will update the pulse value within the workspace 
memory to "80**. Thereafter, the new vital sign is drawn into 55 
the rolling keys 56 which have been updated and the new 
vital sign is stored in the corresponding field in the work- 
space memory (step 1824). Finally, the processor updates 
the scroll bar 58 to reflect the change in the current data 
value (step 1826). 60 

If the event identified in step 1816 corresponds to an icon, 
processing proceeds to step 1830, First, the rolling keys are 
deactivated for the previously active vital sign field (step 
1832) and the rolling keys for the newly chosen vital sign are 
activated (step 1834). Next, the rolling keys for the deacti- 65 
vated and newly activated vital sign fields are inverted to 
display the newly active field to the user (step 1836). 



Thereafter, the scroll bar 80 is redrawn with parameters, 
ranges and current vital signs corresponding to the newly 
selected vital sign field (step 1838). 

When the identified event corresponds to touching the 
scroll bar 80, process flows to step 1840. Once the scroll bar 
is touched, the exact location of the event is determined 
therein and used to identify the corresponding vital sign 
value (step 1842). Then, a pointer is determined which 
identifies the vital sign data value within the workspace 
memory which corresponds to the active vital sign field (step 
1844). This vital sign data value is updated to the new vital 
sign value selected within the scroll bar (step 1846). 
Thereafter, the active scroll keys are updated with the new 
data value (step 1848) and the scroll bar is inverted to reflect 
the new data value (step 1850). When the event occurs 
within the patient information region, processing flows to 
step 1852. In such a case, the patient information screen is 
redrawn. To do so, a calling identifier is set to correspond to 
the patient information screen (step 1854) and control is 
returned to the main loop (step 1856), 

Optionally, when the user touches the patient information 
region, a pop-up window may appear and query the user as 
to whether it is desirable to go to the patient information 
screen or enter a patient identifier through the bar code 
reader. In either case, if the user touches the patient infor- 
mation region, before new patient vital signs have been 
transmitted to the communication server, the user is 
prompted as to whether or not these vital signs should be 
transmitted. When the escape icon is touched, processing 
flows to step 1858, after which the calling identifier is set to 
zero (step 1860). Processing is returned to the main loop 
(step 1862). 

If the screen changing buttons are touched, processing 
flows then to step 1864, after which the selected button is 
determined (step 1866). In step 1867, it is determined 
whether the event corresponds to the transmit button. If the 
selected button corresponds to the transmit button, the 
current patient vitals are constructed into a packet format 
and transmitted to the communication server 12 (step 1868). 
If the selected button does not correspond to the transmit 
button, the calling identifier is set equal to the newly selected 
screen (step 1870). Thereafter, control is returned to the 
main loop (step 1872). 

When the return code within the main loop is set to 
correspond to the view graph display screen (FIG. 3t/), the 
processor determines the active vital sign field (e.g., systolic 
field), and obtains the corresponding default parameters for 
the graph. Thereafter, the screen is cleared and a graph 
having the parameters for the active vital sign field is drawn. 
Next, the vital sign data values for the active vital sign field 
are read from the workspace memory and used to draw the 
graph. 

Optionally, in the view graph screen a series of changing 
function buttons may be displayed along the bottom thereof. 
These buttons would allow the user to automatically select 
another vital sign to view in a graph format without inter- 
mediately returning to the vital input screen. 

In accordance with the above procedure, the handheld 
interface 8 allows for user inputs and displays patient 
information to the user. 
Interface -Server Protocol 

Once the user enters the desired data and wishes to send 
this data to the communications server 12, the user presses 
the transmit function button 70, Once the CPU 32 identifies 
that an event has occurred which corresponds the transmit 
function button 70, the main loop (FIG. 4) calls the transmit 
handling function. FIG. 4 illustrates the process by which 
the CPU 32 transmits data to the communications server 12. 



08/11/2004, EAST Version: 1.4.1 



5,867,688 

13 14 

As illustrated in FIG. 9, each transmission comprises an number. Thereafter, the next segment of data is written to the 

information packet 300 of IR signals corresponding to a packet (step 408) and steps 410 through 420 are repeated, 

packet of data, wherein every packet is constructed with the Once the last packet is transmitted (step 414) and it is 

same predetermined length (e.g., 128 bytes) and in one of determined that no more data remains to be written to the 

two formats. This length is software and operative system 5 packet (step 416), the system exits the transmit routine (step 

definable and may vary. Certain messages transmitted 422). 

between the handheld interfaces 8 and the corresponding Communication Server 

communication servers 12 comprise an amount of data FIG. 16 illustrates a block diagram of the communication 

which is unable to be assembled into a single packet. Thus, server 12 communication server 12 includes an IR 

in such circumstances the transmitting device segments the 10 re ceiver\transmitter 100 which receives and transmits IR 

data into a plurality of equal length packets 300 (referred to communication packets from and to the handheld interface 

as frames). The series of frames form a message 302. g ^ 1R rccc iver transmitter 100 operates in conjunction 

When transmitting a message the first packet/first frame witn an I/0 carcJ 102 t0 store a packet of information from 

thereof is constructed with a header section 304 formed in a each communication channel in the corresponding address 

long header structure followed by a data field 306. The long 15 within a temporary buffer 104. Each communication channel 

header 304 includes a 4 byte command field 308, a 6 byte corresponds to a unique handheld interface 8. For instance, 

user identifying field 310, and a 4 byte message total field the communication server 12 may provide for 128 IR 

312. The command field 308 identifies the process to be channels and thus, the temporary buffer 104 will include 128 

performed upon the subsequent data, the user ID identifies 5uffer i ocauons? w it n each buffer location having sufficient 

the user signed into the handheld interface 8 transmitting or 20 memory to store a complete IR packet 300 (FIG. 9). The 

receiving the packet 308 and the message total 312 identifies num ber of channels is locally definable and may be any 

the total length of the message which will follow. This total desired number. The array locations within the temporary 

length includes all bytes within subsequent packets 300 buffer 104 store the IR pac k ets in the format transmitted 

corresponding to this specific message 302. Thereafter, a from the handheld interface 8 as described above, 

data field 314 (having 114 bytes in a packet with a 128 byte 25 The cornmunications ^rver 12 further includes an input 

structure) follows. buffer 108 which represents a storage space used by the CPU 

If the message includes more data than will fit in a single m when converti kets from the format stored m tne 

packet, subsequent packets/frames are transmitted. These t ary buffcr 104 to message lists with a different format 

subsequent packets/frames are constructed with a short tQ be transmitted t0 lhe command servers 14 . input 

header -structure ^316 pr^ece<hng the data segment 318 Tlie 30 buffer 1Q8 cnts an cach clemcnt of which 

short header 316 includes a 4 byte command 320 and a 4 the COMJNFO structure (explained below), 

byte positioning packet 322 identifying number to enable the t . t , » . , 

> i . , fo • „ f t u a „o^t Each element of the input buffer 108 array is accessed 

receiving device to determine the position ot the packet . * r ..^o * i . • * 

within the overall message. Packets containing a short ^ ed fi on th * devicc «™ bcr * ^ i I n t V^" 

header 316 include a 120 byte data field for a packet formed 35 f * ces 8 are bein * ^ the in P ut buffer 8 wdl mclude 128 

with 128 bytes. During transmission, the first packet of each c emen * 

message includes a long header 304 structure followed by a The communications server 12 further includes a message 

data field, with each subsequent packet within the message buffer which is utilized to store the actual data for each 

including a short header 316 instructed followed by a data complete message sent from the hand held interface once all 

field. In this manner, the device is able to increase the 40 of the necessary packets have been transmitted by the 

amount of data transmitted within each packet for long handheld interface 8 and reassimilated by the CPU 106 into 

messages. The transmitting device need not send the user ID * single message. The COM_INFO stored in the input 

and the message total more than once for a given message buffer 108 includes a pointer MSG_From_HH into the 

since the receiving device is able to associate corresponding message buffer to the beginning of the corresponding data 

packets with a single message 302 based on the packet 45 string. Once every packet 300 for a message 302 is received 

number 322 and communication channel. and thc corresponding data is stored in the message buffer 

To transmit a message (FIG. 10), the CPU 32 reads the and the COM_INFO is stored in the input buffer 108, the 

current data from the workspace memory 200 in the RAM CPU 106 constructs a message list therefrom. Each message 

35 (step 400). Next, the CPU 32 determines the length of the list to be processed by the command server 14 is stored on 

message and the ID of the user signed in to that handheld 50 °n e of a process queue 114. The message list includes a 

interface 8 (step 402). The CPU 34 constructs a packet P ointer to the corresponding data string in the message 

header formed with the long header structure (step 404). The buffer 110. Each message list received from the command 

CPU 34 clears the packet number (step 406) and writes the server 14 is initially stored in a transmit queue 116 prior to 

data to the transmit buffer (step 408). If the packet is full bei ng converted back into packets 300 and transmitted to the 

(step 410), the CPU 32 transmits the packet and clears the 55 handheld interface 8. The message list includes a pointer to 

buffer (step 412). If the packet is not full, it determines if a corresponding data string which is stored in the message 

more data exists to write to the buffer (step 414). If no more buffer 110 when it is received from the command server 14. 

data exists, it transmits the packet. If more data exists, it The process and transmit queues are operated in a first- 

against writes to the packet. In step 416, it is determined if in-first-out sequence such that each message is processed or 

more data exists, and if not it exists. If so, the packet number 60 transmitted in the order in which it is placed in the queue, 

is incremented (step 418). Next, the CPU 34 constructs a The transmit and process queues 112 and 114 constitute 

partial short header for the second frame to be transmitted in dynamic queuing systems which attach message lists in a 

this message (step 420). The partial header includes the code linked list structure. Each message list include the data 

for the corresponding command and the current packet structure illustrated below: 
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MESSAGE LIST 

COM_INFO Data File Command MSG_TO __HH MSG__LEN Prev 

(Integer) (1) (Pointer) (Long Integer) MSG_LST 

(Pointer) 

COM_INFO 

Device CMD Packet User ID User MSG MSG MSG 

Number (4) Number lb ID Total Length From 

(Integer) (Long (6) From (Long (Long HH 

Integer) (6) Integer) Integer) (Pointer) 



The message list data structure includes a first section 
COM_INFO dedicated to, and containing information 
concerning, messages received from the handheld interface 
8. The next four fields represent fields which are created 
immediately before transmitting a message list to the com- 
mand server 14 and another communications servers 12. The 
final field (Previous MSG_LST) is used as a pointer to the 
subsequent message list within the queue to be processed. 
The first section COM_INFO includes a device number 
uniquely identifying the handheld interface transmitting the 
message. The device number is generated by the I/O card 
102 when the CPU 32 requests a packet 300 from the 
temporary buffer 104. The device number is produced 
depending upon the communications channel being 
accessed. The command (CMD) includes the structure of the 
CMD field transmitted in the header of each packet 300 (i.e., 
the 2 byte database ID, 1 byte command ID and 1 byte 
reserved). 

The command (CMD) represents the command to be 
processed in accordance with the corresponding message 
being transmitted to or from the handheld interface 8. The 4 
bytes within the command are separated such that the first 
two bytes identify the database to be processed when 
performing the command, the third byte stores a number 
corresponding to the specific command to be performed, and 
the fourth byte is reserved. By way of example, with respect 
to the third byte, numerals 1-127 represent commands to be 
processed by the command server, while numerals 128-255 
represent to a command from the handheld interface 8. As 
noted above, the use of shorthand code numbers for specific 
commands reduces the amount of data to be transmitted to 
and from the handheld interface 8. 

The Packet Number is a long integer which is incre- 
mented each time a packet is appended to a message on the 
input buffer 108. The User_ID_To is a 6 byte value added 
by the handheld interface 8 to identify a destination user. If 
set to zero, the destination is the communications server. The 
communications and command servers determine which 
server to send the command to. This value if non-zero will 
identify the user of a handheld interface 8 desires to com- 
municate therewith. The User_JD__From is a 6 byte value 
added once at login time. This user ID is assigned to the 
channel to identify who is logged in at that channel. This 
value is maintained until the person signs out. Thus, the user 
ID will only be transmitted once during a login session. The 
communications server 12 keeps track of each User ID 
signed onto handheld interfaces served by that communica- 
tions server 12. The message total length (MSG_Total) is a 
value assigned by the handheld interface 8 or by the com- 
mand server 14 when a message is transmitted. The message 
length (MSGJLEN) is a value updated by the short and long 
header parsing functions to keep track of the length of a 
message in the message buffer 110 as the packets for the 
message is added thereto. The message length field is 



initially tested by the communications server 12 when 

15 processing each packet in the temporary buffer 104 to 
determine if the packet is in a long or short header form. The 
message pointer field (MSG_From_HH) is a pointer into 
the message buffer to the location of the actual data message. 
The MSG„From_HH pointer is updated each time a new 

20 packet is appended to a message. 

The message list structure includes the above COM_ 
INFO structure as in additional to a Data_File field that 
represents an integer identifying the database, written from 
the COM__INFO structure, to be processed in connection 

25 with the corresponding command. The command (CMD) 
field represents a one byte command, written from the 
COM__INFO structure, to be processed. The MSG_To_HH 
field represents a message pointer used to point to the data 
compiled by the command server in connection with this 

30 message which will ultimately be sent to the handheld 
interface 8. The MSG_LEN field represents a long integer 
identifying the current length of the data corresponding to 
the message and stored in the message buffer. The 
Previous_MSG__LST represents a pointer pointing to the 

35 next message to be processed. The previous message pointer 
enables the system to accomplish dynamic queuing for the 
process and transmit queues. 

FIG. 11 illustrates the processing sequence by which the 
communication server 12 receives messages from the hand- 

40 held interface 8, processes these messages and transmits 
these messages to the command server 14. First, the I/O card 
102 is initialized, along with the communication channels, 
buffers and queues (step 700). Next, the data structures for 
the message list, COM_INFO, CMD, and short and long 

45 headers are set up (step 702). A current channel to be read 
by the I/O card 102 is initialized to the first channel (step 
704). Next, the current channel is tested to determine 
whether data is being transmitted thereon from the corre- 
sponding handheld interface 8 (step 706). If data is present, 

50 the packet of transmitted data is read and stored in the 
temporary buffer 104 (step 708). The packet of data is stored 
within the temporary buffer 104 at the array address corre- 
sponding to the current channel. A channel identifying 
number corresponding to the transmitting handheld interface 

55 8 is also assigned thereto by the I/O card 102. 

Next, a check sum field within the data packet is tested to 
determine whether the transmitted data is valid (step 710). If 
the data is invalid, the communication server takes the 
necessary corrective actions (step 712). If the data is valid, 

60 the CPU 106 requests the channel number (step 714) and the 
packet 300 from the I/O card 102 and utilizes the channel 
number to index the correct corresponding element within 
the input buffer 108. Next, it is determined whether a packet 
is an initial frame or a subsequent frame of a message (step 

65 716). To effect this test, the message total field, within the 
element of the input buffer 108 corresponding to the current 
channel, is read and compared to zero. If the message total 
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field equals zero, then a packet has not yet been written to 
this element of the input buffer 108. Thus, the packet being 
read is identified as an initial packet which will include the 
long header structure. Otherwise, the packet is identified as 
one containing the short header structure. In either case, the 
packet number is incremented within the currently indexed 
element of the input buffer 108. 

If the packet contains the long header structure, process- 
ing moves to step 718 in which the parse long header 
function is invoked. If the packet includes the short header 
structure, processing moves to step 720 where the parse 
short header function is invoked. 

FIG. 12 and FIG. 13 illustrate the parse long and short 
header functions. Within the parse long header function, the 
first four bytes of the data packet within the temporary queue 
is read as the command (step 722). This command is 
compared with a list of valid commands and if the command 
is invalid the processor takes the necessary corrective action 
(step 724). If the command is valid, the command is written 
to the command field within the element of the input buffer 
108 indexed by the corresponding channel number (step 
726). Next, the subsequent six bytes of the packet within the 
temp buffer is read as the user ID, if present, of the 
destination user for the attached message/data. This six byte 
ID is stored in the user ID_To field of the element within the 
input buffer 108 indexed by the current channel number 
(step 728). The User ID, corresponding to the signed on user, 
is added to the UserID_From field of the indexed element. 

Next, the subsequent four bytes are read from the packet 
within the temporary buffer 104 as the total length of the 
following message (e.g., the total number of bytes to follow 
within one or more packets corresponding to the present 
message) (step 730). The four byte value representing the 
message total is converted to a long integer (step 732) and 
assigned to the message total field within the element of the 
input buffer 108 indexed by the current channel number 
(step 734). Thereafter, the data section within the packet is 
written to the message buffer as a data string and the length 
thereof is stored within the message length field within the 
presently indexed element of the input buffer 108 (step 736). 

A message pointer pointing to the data string within the 
message buffer 110 is stored within the message pointer field 
of the indexed element within the input buffer 108 (step 
738). Finally, the element of the temporary buffer 110 is 
cleared (step 740). In this manner, steps 718-740 parse 
through a packet having a long header structure, create the 
COM__INFO structure within the input buffer 8 and store the 
message 302 from the handheld interface 8 within the 
message buffer 110. 

Returning to FIG. 11, if in step 716 it is determined that 
the packet is not an initial packet, then the short header 
function is invoked (see FIG. 13). First, the first four bytes 
of the packet are pulled (step 742) and compared with the 
value in the command field of the currently indexed element 
within the input buffer 108 (this command is indexed based 
on the channel number) to determine if these commands are 
the same (step 744). If not, the system takes the necessary 
corrective actions (step 746). If the commands correspond, 
the packet number within the short header is pulled (step 
746), converted to a long integer (step 748) and compared to 
the packet number (plus one) within the indexed element of 
the input buffer 108 (step 750). These packet numbers must 
correspond to ensure that the received packet is the next 
packet to be added to the input buffer 108. If the packet 
numbers correspond, the present packet is identified as part 
of the message corresponding to the presently indexed 
element within the input buffer 108 and processing flows to 
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step 752, else it returns. If the packet is not matched based 
on above criteria, then a corrective action is taken. 

Next, the data within the temporary buffer 110 is pulled 
(step 752) and the portion of the message already stored in 

5 the message buffer 110 is read (step 754). The new data is 
added to the end of the stored message and the new total 
string is rewritten to the message buffer 110 (step 756). The 
message pointer (MSG _From_JiH) and the message length 
(MSG_LEN) are updated within the corresponding fields of 

10 the CONUNFO of the indexed element of the input buffer 
108 (step 758). Thereafter, the control returns to the main 
process (step 760). 

Referring to FIG, 11, once control is returned to the main 
program, the current channel is incremented (step 760). 

15 Next, it is determined whether all channels have been 
checked (step 762). If so, control is set to the processing 
sequence (at point A). If all of the channels have not been 
checked, control returns to step 706. This process is con- 
tinuously performed until all of the channels have been 

20 checked thereby transferring all packets of data from the 
temporary buffer 104 to the input buffer 108 and message 
buffer 110. 

Next, processing moves to the processing queue sequence 
(FIG. 14) to move completed messages 302 to the process- 

25 ing queue 112. First, the current element pointer into the 
input buffer 108 is set to the first input buffer element (step 
800). Then, it compares the message total length (MSG_ 
Total) with the message length (MSG_LEN) to determined 
whether a complete message corresponding to the current 

30 element within the input buffer 108 has been received and 
stored in the message buffer (step 802). If not, the incom- 
plete message remains on the input buffer 108 and the 
current element pointer is incremented (step 804) and the 
process returns to step 802. 

35 If the complete message for the current element has been 
received, the message is placed on the processing queue 
(step 806) by creating a message list therefor. To do so, the 
command information (COM_JNFO ) of the current ele- 
ment of the input buffer 108 is written to the processing 

40 queue 112 and stored in the command information (COM_ 
INFO ) section therefor. As the corresponding message 
represents a transmission from the handheld interface 8 to 
the command server 14, the next four fields of the indexed 
message list element in the processing queue remain unde- 

45 fined. This message list is "pushed onto the back" of the 
processing queue by storing, in the preceding message list in 
the processing queue, a pointer to the current message fist. 
This pointer is store in the final field (Previous_MSG_ 
LST) within the previous, most recent message list added to 

50 the processing queue (step 806). 

Once the command information has been moved to the 
processing queue, the corresponding element of the input 
buffer 108 is cleared (step 808). Thereafter, the current 
element pointer into the input buffer 108 is incremented 

55 (step 810) and it is determined whether or not every element 
of the input buffer 108 has been tested (step 812). If not, 
processing returns to step 802 and the next element within 
the input buffer 108 is processed. If processing is done on the 
input buffer 108, control moves to the process the message 

60 lists on the processing queue. 

The first element of the processing queue is tested to 
determine whether a command is stored therein (steps 900 
and 902). If a command exists on the processing queue, this 
command is "dequeued" (step 904) by reading the message 

65 information from the processing queue (which is stored in 
the message list structure). The command field (CMD) 
within the COM_JNFO section of the message list is read. 
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The message is parsed into specific components (step 906), munications server. The command server utilizes a conven- 

by reading the first two bytes of the command field, con- tional software package for managing these databases, such 

verting these bytes to a long integer form and storing the as Pro-tree (version 2.0). Other database managing systems 

data base identifier in the Data_File field of the message list may be used to access the data base, such as DBase, 

(step 908). Next, the third byte of the command (CMD) field s CodeBase, B-Trieve, Cisam and the like. Particular com- 

in the COM_INFO structure is read and stored in the mands wthin the conventional management system are 

Command field of the message list (step 910). Then the called depending upon the command code and database 

actual data message is appended to the message list structure c0 ^ tr ™ ttc < 1 ™ ih ™ ^ mcss »* e ils u l ; ^ 

based on the message pointer (MSG TO HH) and the HG - ]? ^trates the process by which the command 

* * /x*c?n ™ TTri\ JTu — i *u „ server 14 invokes the database management functions. First, 

Zf^VvT 1 ^ rT? J c?^ an l mCSSagC r g the command server 14 receives the receives a message (step 

(MSG LEN) are reset (step 912). The communications 90Q)j {ndta ^ the kte m list structure f * llo Ved 

server 12 sends the message to the appropriate command by ^ data message Next7 the command ser ver 14 reads the 

server 14 based upon the database and command code (step data base file field ( step 902 ) and determines whether that 

512). data t, asc code is valid for the present command server 14 

Next, the previous message pointer (Previous_MSG_ is ( ste p 904). If not, it returns an error message (step 906), If 
LST) is read from the current message list to determine the SOj coa trol is transferred to the database routine correspond- 
next message to be processed on the queue (step 914) and ing to the command code (CMD) in the Command field of 
control is returned to step 902. In this manner, each message the message list (step 908). Next, it is determined whether 
upon the processing queue 112 is parsed through and trans- the command code is correct for the addressed database 
mitted to the appropriate command server 14. When no more 20 (step 910). If not, it returns an error code (step 906). If so, 
commands are on the processing queue, control is moved to it accesses the message data within the message list and 
the create transmit queue module (step 916) (FIG. 15). performs the appropriate operation upon the data base (step 

FIG. 17 illustrates the process by which the communica- 912). Thereafter, it constructs a return message using the 

tion server 12 processes messages upon the transmit queue data returned from the database into the structure of the 

which are to be sent to the handheld interface 8. First, the 25 message list (step 914) and quits (step 916). 

first message upon the transmit queue is tested (step 1000) To invoke the database managing functions, the command 

to determine whether data is contained therein (step 1002). number is processed within a case statement, whereby each 

jr i t ■ . • ,i i u„ tu* case within the case statement corresponds to a unique 

If data exists the message is dequeued by taking he ^ th ^ te 

message off the transmit queue (step 1004). Next, the routines For ^ command number ? re ^ ntan 

command information from the message list is read and a 30 add coramand> ^ thus> case « 7 » wou i d di rect the command 

long header constructed for the first packet to be transmitted servef tQ read the data ffom the message and wite tnis data 

to the handheld interface 8 for the message (steps 1008 and t0 the next address w i tn in the database. Similarly, the 

1009). Next, the data from the message is written to the command number within the message may represent a read 

packet and transmitted (step 1010 and 1012). Thereafter, it or request operation, in response to which, the correspond- 

is determined whether additional data remains to be trans- 35 mg case WO uld direct the command server to read the desired 

mitted to the handheld interface 8 (step 1014). If yes, a short information from the database corresponding to the user ID 

header is constructed (step 1015) and additional data from transmitted within the message. The command server the re - 

the message is written to the packet containing the short after adds this data to the message and retransmits it to the 

header (step 1016). communications server. 

Once constructed, the packet containing the short header 40 From the foregoing it will be seen that this invention is 

is transmitted (step 1018) and processing returns to step one well adapted to attain all ends and objects hereinabove 

1012 at which it is determined if more data remains. This set forth together with the other advantages which are 

loop is repeated until the entire message has been trans- obvious and which are inherent to the structure, 

formed from the message list structure into data packets and It will be understood that certain features and subcombi- 

transmitted to the handheld interface 8. Once the entire 45 nations are of utility and may be employed without reference 

message has been transmitted, control passes to the next to other features and subcombinations. This is contemplated 

module (step 1020). by and is within the scope of the claims. 

The communications server 12 tests the communication Since many possible embodiments may be made of the 

bus 6 and determines if messages have been sent from other invention without departing from the scope thereof, it is to 

communication servers. First, the communications bus is 50 be understood that all matter herein set forth or shown in the 

tested to see if a message exists (step 1100). If a message accompanying drawings 1-19 is to be interpreted as 

exists, the message is read (step 1104) and the command illustrative, and not in a limiting sense, 

therefor is decoded (step 1106). Thereafter, the command is The following appendix sets forth descriptions of the 

tested to determine whether the message should be trans- modules and functions used by the present system, 

mitted to a corresponding handheld interface 8 or whether 55 Glossary 

the message should be transmitted to a command server key — an area of the screen that has been registered with 

connected to the communication server 12 (steps 1108 and the opening system as an area where an event is expected. 

1110). Thereafter, the message is placed on the transmit or If an event does not occur within this area, an integer 

processing queue depending upon the destination of the identifier will be returned by the operating system indicating 

message (steps 1112 and 1114). Thereafter, control is 60 that the event did occur. 

returned to the main program (step 1116). This process is event — the screen was touched, if it was touched in an 

continuously repeated until the communication server 12 is area defined by a key, then return the identifier, 

turned off. Once turned off, the communications channels scrolling text window — a key where scrolling text will 

are closed and the system is turned off. reside. 

Command Server 65 scroller — a key associated with the scrolling text window, 

The command server operates to update the correspond- the scroller has a bar in it to indicate where the text within 

ing databases based upon messages received from the com- the text window is in relationship to the rest of the text. 
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scrollbar — the tool used for entering vitals (darkened 
from the very bottom of the key to the value chosen by the 
user). 

rolling key — a key with a digit in it, when the key is 
touched, that digit is incremented. If the digits value is 9 and 
it is incremented, it will contain the value 0 with no carry 
performed. 
Module 

scrollbar.c — contains all functions for the scroll bar func- 
tions to be used by other modules. 

init_scroll_bar — initializes all necessary variables and 
draws all of the detail. 

get_scroll_bar_value — upon an event in the scroll bar 
key, this routine is called and it handles that event, then 
it returns the value and that the scroll_bar is pointing 
to (the value point pointed to by the user). 

seL_scrolL_bar_value — the user can set the value any 
time, functions to be used internally by this module 
draw_scroll_bar — draws the inside of the scroll_bar. 
Module 

vital__input — contains all the functions used to perform 
the vital input 

note — the Mode value indicates what is being input at the 
moment, if the user has chose systolic, then the systolic 
rolling keys are inverted and activated, and the scroll 
bar will have the systolic data in it. 

possible modes — systolic, diastolic, pulse, temperature, 
respiratory. 

Write_Keys_Data — this routine redraws the rolling keys 
associated with a certain mode, (example, if the mode is 
pulse and the user somehow changes the value, this routine 
draws the 100s value in the leftmost key, the 10s value in the 
middle key, and the is value in the rightmost key). 

ChangeMode — changes the mode of the screen, this 
involves (1) turning off the old mode (example — pulse); (2) 
turning on the rolling keys of the new mode (example — 
systolic) so now an event may occur — also invert the keys 
to that they are white on black; and (3) calling Init_scroll_ 
bar to redraw the scroll bar with the new modes details. 

EnterVitalsDraw — draw the detail on the entire screen 

(1) write patients name 

(2) write last date and time that the vitals were entered 

(3) write the last vitals values 

(4) turn off all rolling keys 

(5) change the mode to systolic by calling changemode 
inc_value — increment the values in the rolling keys, then 

call Write_Keys_data. 

inc_temp — same as inc_value, but allow the 100's key 
to contain the values 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11. 

Do_vital_input — THE MAIN ROUTINE 

(1) calls EnterVitalDraw 

(2) contains the case statement that handles events. 
Module 

graph. c — draws the graph on the screen. 

make__graph — receives x, y values, x axis label, y axis 
label, the type of data that the x and y values are (time, short 
int, int, long int, float, etc.) and draws the graph, depending 
upon the type of data in x and y, it calls a simple routine that 
turns the x, y values into x, y plotting points on the screen. 
Module 

patinputc — contains all of the functions used to pick a 
patient. 

DoPatientlnput — does the entire screens functionality 
within this one routine. 

1 — init_scroller — passes in the patient list and the two 
keys (scroller key and scrolling text key). 
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2 — handles all events, 
events 

in the case that the user picks A-Z, that letter is concat- 
enated onto the search string which is initially empty, 
5 then a sequential search upon the text strings is per- 
formed to find the first text which is greater in alpha- 
betic value than the search string, then that value is 
chosen via the function set__scroller_value. 
in the event the user touches the scroller then get_ 
10 scroller_jvalue is called. 

in the event the user touches the scrolling text key, then 
get_scroll_text_value is called. 
Module 

vitalj.c — the starting point of the program, contains all 
is function calls. 

note Every single "screen" that is called from any 

other "screen" will be associated by a Calling Identifier 
(CauTD). 

DoMainMenu — two main case statements 
20 case statement #1 

handles the events of the main menu, if an event occurs 
in any of the keys of the main menu, then store the 
CallED in the variable called RetumCode. 
case statement #2 
25 while RetumCode is not equal to 0 loop the case 
statement. 

since the RetumCode is not 0, call the appropriate 
function associated with the Calling Identifier stored 
in the variable, the function called will eventually 
30 return a code that will again be stored in the variable 

RetCode. 
Module 

scroller.c — contains all functions for the scrolling text 
windows. 

35 functions to be used by other modules 

init__scroller — initializes all necessary variables and 

draws of all the detail. 
get_scroller_value — upon an event in the scroller key, 

this routine is called and it handles that event, then it 

40 

returns the value that the scroller is pointing to (in our 
program, this value is the index into an array of 
strings — points to the text that was picked). 
set_scroller_value — the user can set the value any time. 
45 get_scrolL_text__value — upon an event in the scroll text 
window, this routine is called and it handles that event, 
then it returns the same value as does the get_scroller_ 
value function, 
functions to be used internally by this module 
50 draw_scroller — draws the bar inside of the scroller, then 
calls draw_scroll_text. 
draw_scroll_text — draws all of the text that appears in 

the scrolling text window. 
invert_picked__text — inverts the text that is being 
55 pointed to by the user. 
Major Functions 

open_ir — used to initial the IR communication with the 
AndroDat Card and setup the communication channels with 
each device. 

60 close _ir — used to close all communication channels with 
the hand held. 

init„com — info — used to reset and clear all data con- 
tained for one specified com) info buffer. This routine is 
called initially to initialize each buffer and ready to receive 
65 data. After a message has been received and put on the 
process queue, this routine is used to clear the old data and 
ready the input buffer for the next command. 
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collect__messages — this routine will read through each 
input channel to see if a message exists. If one exists, then 
the message will be read into a temporary buffer and passed 
to the routine place_jnessage for placement on the input 
buffer. 

place__message — this routine will determine if the mes- 
sage being read in is the first or subsequent message. If the 
message is the first packet, then the routine parse_long_hdr 
is called. If the packet is the second or subsequent message, 
the routine parse — short_hdr is called. 

parse_short hdr — this routine is used to parse the struc- 
ture tmp_buffer, validate the command being sent along 
with the correct packet number, then place the data in the 
appropriate in buffer message structure. This routine is 
called after the initial command packet is sent. 

parse_long_hdr — this routine is used to parse the struc- 
ture tmp_buffer, validate the command being sent. This 
routine then initializes the in__buffer structure and finally 
places the data in the in_buffer messages structure. This 
routine is called when a handheld device sends its initial 
packet for requesting a command. 

comm_server — this routine is the main routine which 
controls the logic flow of the entry communication server 
system. 

process^in buffer — this routine is used to search the 

in_buffer for completed messages to e placed on the process 
queue. This routine determines if a messages is finished if 
msg_total= — msg_len and msg__total >0. This routine 
calls ENQUEUE to physically put the message on the 
process queue. 

process_cmd — this routine is used to take the next mes- 
sage off the command queue then send it to the correct server 
for processing. This routine calls the dequeue function to 
physically dequeue the item off the command queue. 

process_transmit — this routine is used to take the next 
message off the transmit queue then send it to the correct 
server for processing. This routine calls the dequeue func- 
tion to physically dequeue the item off the transmit queue. 

packet__msg — this routine is used to physically send the 
message from the communication server to the handheld 
computer via the AndroDat Card. It is responsible for all 
packet of the data and verify of successful transmission. 

enqueue — this routine takes completed messages and 
places them on the queue. A parameter is passed to which 
queue to place the message along with the data to queue. 

dequeue — this routine will take messages off the queue 
and place in a temporary buffer to be processed by the 
communication server. A parameter is passed to which 
queue to process along with the temporary space to put 
message. 

nulqueue — this routine is used to initialize a queue and 
prepare it to start receiving data. Call to this routine will 
destroy any data existing in the queue. 

com_info — this structure is used to store the incoming 
message from the handheld 

in_buffer — this is an array of the structure com^info. 
This structure is used to hold the individual messages being 
received from the handheld computers. 

message_list — this structure is used to serve as the queu- 
ing functions for the command processing and data trans- 
mission. 

long hdr — this is the structure of the header for initial 

communication to the server. 

short_hdr — this is the structure for second and subse- 
quent communications of the second command. 

What is claimed is: 

1. A multi- tiered computing system comprising: 

a first computing tier having a master server computer, the 

master server coupled to a master database of master 

data records; 

a second computing tier having a plurality of input 
computers, each input computer coupled to a respective 



local database of local data records, each local database 
replicated from the master database; and 
a third computing tier having a remote portable computer, 
the portable computer being in communication with a 
5 select input computer for accessing local data records, 
the portable computer comprising: 
a CPU for controlling operation of the portable com- 
puter; 

an interface memory for storing software to control the 
CPU and to store temporarily at least one data set 
each data set having multiple data fields for storing 
data values; and 
a touch sensitive display screen for displaying at least 

35 a data I/O screen and for sensing contact by a user, 

the CPU defining multiple virtual regions upon the 
data I/O screen, each corresponding to a data field, 
the display screen sensing and informing the CPU of 
contact by the user within a virtual region, the 

20 display screen displaying within each virtual region 

a data value for the associated data field from a 
current data set for a current matter, the CPU iden- 
tifying a virtual region contacted by the user and 
effecting an interface control associated therewith 

25 and wherein the user modifies data values within a 

correspond active data field by pressing the associ- 
ated virtual region. 

2. The system of claim 1 wherein the input computer 
comprises: 

30 a command server for managing the local database; and 
a communications server for receiving and transmitting 
packets of information to and from the portable 
computer, the packets being constructed in a first 
format having a header and a data segment, the com- 

35 munications server converting the packets to a second 
format and constructing a message therefrom, the com- 
munications server transmitting the message to the 
command server which returns a message list, the 
communications server converting the returned mes- 

40 sage list to the first format and transmitting a packet of 
information to the portable computer. 

3. The system of claim 1, wherein the display screen 
illustrates the current data set in at least one of a scroll bar 
format and a rolling key format. 

45 4. The system of claim 1 wherein the display screen 
displays one of a set of display screens including the data I/O 
screen and including a menu screen and a graphing screen, 
wherein each selection from the menu screen corresponds to 
a virtual region and an associated processing sequence. 

50 5. The system of claim 1, wherein each virtual region 
corresponds to a predefined processing sequence which is 
initiated by the user by contacting the associated virtual 
region. 

6. The system of claim 1, wherein the data I/O screen 
5S further displays multiple icons, each being uniquely associ- 
ated with a data field. 

7. The system of claim 3, wherein said rolling key format 
includes multiple sets of displayed keys, each set corre- 
sponding to a unique data field, each displayed key within 
each set corresponding to a digit within a related data value 

60 and to a unique virtual region. 

8. The system of claim 7, wherein the user adjusts a 
current data value of an activated data field by contacting a 
virtual region corresponding to a displayed key within the 
set of displayed keys associated with the active data field. 

65 9. The system of claim 3, wherein the scrolling bar format 
includes a displayed scroll bar with a current level corre- 
sponding to a data value of an activated data field. 
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10. The system of claim 3, wherein the user adjusts a 
current data value of an activated data field by contacting a 
virtual region corresponding to a scroll bar at a level 
corresponding to a desired data value for the activated data 
field. 5 

11. The system of claim 3, wherein the data I/O screen 
includes virtual regions corresponding to change function 
keys, each of which directly accesses a corresponding one of 
a plurality of screens, the CPU controlling the display screen 

to display a screen corresponding to a contacted change 10 
function key. 

12. The system of claim 3, wherein the display screen 
illustrates a data set inquiry screen used to allow the user to 
select a new data set for a new matter, the CPU controlling 
the display screen to display a scrolling text window, within 15 
the inquiry screen, which exhibits a current data set header 
and multiple preceding and succeeding data set headers. 

13. The system of claim 12, wherein the data inquiry 
screen exhibits a scroll bar proximate the scrolling text 
window to enable the user to scroll through a plurality of 20 
data sets by contacting the scroll bar at a corresponding 
location. 

14. The system of claim 12 wherein the data set inquiry 
screen includes virtual regions corresponding to a virtual 
keypad to enable the use to enter at least a portion of a 25 
desired data set header, the CPU automatically searching the 
data set headers stored in the interface memory based upon 
the entered portion of the data set header, the display screen 
displaying a data set header which corresponds closest to the 
entered position of the data set header. 30 

15. The system of claim 1, wherein the portable computer 
further comprises an optical scanner for reading bar codes 
containing at least portions of the data set, the display screen 
displaying a virtual scan button to allow the user to read bar 
code data from a bar code associated with a corresponding 35 
matter. 

16. The system of claim 1, wherein the interface memory 
includes a data set storage section for storing data set 
headers and identifiers associated with a present user, each 

of the headers and identifiers uniquely identifying a data set. 40 

17. The system of claim 1, wherein the interface memory 
includes a working space for storing all data values entered 
by the user and transmitted to the portable computer from a 
remote communications server, wherein, when the CPU 
requests a data set from the communications server, the CPU 45 
redefines a current data structure within the working space 

to correspond to a predetermined expected format of a 
returned data set from the communications server. 

18. The system of claim 1, wherein the portable computer 
includes a temporary buffer for storing incoming and out- 50 
going data sets transmitted to, and received from, a remote 
communications server. 

19. The system of claim 1 wherein the input computers are 
coupled to the master server by a bus, 

20. The system of claim 1 wherein the portable computer 55 
communicates with the select input computer over a wireless 
data link. 

21. The system of claim 20 wherein the wireless data link 
is an infrared communication channel. 

22. The system of claim 1 wherein the input computer 60 
comprises a communication server associated with the select 
local server computer, the communication server computer 
interfacing the portable computer with the local database. 

23. The system of claim 1 wherein data is transmitted 
between the select input computer and the portable computer 65 
in an encoded format to reduce bits of information being 
transmitted. 
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24. The system of claim 23 wherein the portable computer 
includes remote data records replicated from the local data 
records of the local database, the remote data records further 
including modified data, the encoded format comprising 
transmitting the modification operations from the portable 
computer to the input computer. 

25. The system of claim 1 wherein each input computer 
serves a local area and the select input computer is selected 
based on the respective local area and the position of the 
portable computer. 

26. The system of claim 1 wherein the data records 
include medical data. 

27. In a data acquisition and retrieval system, a method for 
entering and retrieving a plurality of data sets through a 
wireless handheld user interface, the method comprising the 
steps of: 

a) defining virtual regions within a display screen along 
with corresponding event identifiers; 

b) drawing a main menu with multiple, virtual menu 
selections, each of which correspond to a virtual 
region; 

c) sensing an event denoting contact by a user; 

d) determining whether the sensed event is in a defined 
virtual region, and if so, obtaining a unique identifier 
corresponding to the sensed event; 

e) performing a processing sequence associated with the 
unique identifier and waiting for a return identifier upon 
completion of the processing sequence; 

f) performing a new processing sequence associated with 
the return identifier if the return identifier does not 
correspond to the main menu, and waiting for a return 
identifier upon completion of the new processing 
sequence; 

g) repeating steps a) through f) when said return identifier 
corresponds to said main menu; 

h) repeating step f) and g) so long as said return identifier 
does not correspond to said main menu; 

i) determining whether a list of data set headers, corre- 
sponding to a currently logged-in user, is stored within 
the interface; 

j) when the list is absent, performing steps jl through j3 
as follows: 

jl) requesting the list from a remote communications 
server connected to the system; 

j2) setting up a data structure within the interface based 
upon an expected structure of the list; 

j3) storing a returned list received from the communi- 
cations server; and 
k) displaying a portion of the list. 

28. A multi-tiered computing system comprising: 

a first computing tier having a master server computer, the 
master server coupled to a master database of master 
data records; 

a second computing tier having a plurality of input 
computers, each input computer coupled to a respective 
local database of local data records, each local database 
replicated from the master database; and 

a third computing tier having a remote portable computer, 
the portable computer being in communication with a 
select input computer for accessing local data records, 
the portable computer comprising: 
a CPU for controlling operation of the portable com- 
puter; 

an interface memory for storing software to control the 
CPU and to store temporarily at least one data set 
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each data set having multiple data fields for storing 
data values; and 
a touch sensitive display screen for displaying at least 
a data I/O screen and for sensing contact by a user, 
the CPU defining multiple virtual regions upon the 5 
data I/O screen, each corresponding to a data field, 
the display screen sensing and informing the CPU of 
contact by the user within a virtual region, the 
display screen displaying within each virtual region 
a data value for the associated data field from a 
current data set for a current matter, the CPU iden- 
tifying a virtual region contacted by the user and 
effecting an interface control associated therewith, 
and wherein the portable computer includes a tem- 
porary buffer for storing incoming and outgoing data 
sets transmitted to, and received from, a remote 15 
communications server. 

29. The system of claim 28 wherein the input computer 
comprises: 

a command server for managing the local database; and 
a communications server for receiving and transmitting 20 
packets of information to and from the portable 
computer, the packets being constructed in a first 
format having a header and a data segment, the com- 
munications server converting the packets to a second 
format and constructing a message therefrom, the com- 25 
munications server transmitting the message to the 
command server which returns a message list, the 
communications server converting the returned mes- 
sage list to the first format and transmitting a packet of 
information to the portable computer. 30 

30. The system of claim 28, wherein the display screen 
illustrates the current data set in at least one of a scroll bar 
format and a rolling key format. 

31. The system of claim 28 wherein the display screen 
displays one of a set of display screens including the data I/O 
screen and including a menu screen and a graphing screen, 35 
wherein each selection from the menu screen corresponds to 

a virtual region and an associated processing sequence. 

32. The system of claim 28, wherein each virtual region 
corresponds to a predefined processing sequence which is 
initiated by the user by contacting the associated virtual 40 
region. 

33. The system of claim 28, wherein the data I/O screen 
further displays multiple icons, each being uniquely associ- 
ated with a data field. 

34. The system of claim 28, wherein the interface memory 45 
includes a data set storage section for storing data set 
headers and identifiers associated with a present user, each 

of the headers and identifiers uniquely identifying a data set. 

35. The system of claim 28, wherein the interface memory 
includes a working space for storing all data values entered 50 
by the user and transmitted to the portable computer from a 
remote communications server, wherein, when the CPU 
requests a data set from the communications server, the CPU 
redefines a current data structure within the working space 

to correspond to a predetermined expected format of a 55 
returned data set from the communications server, 

36. The system of claim 28 wherein the portable computer 
communicates with the select input computer over a wireless 
data link. 

37. The system of claim 28 wherein the input computer 60 
comprises a communication server associated with the select 
local server computer, the communication server computer 
interfacing the portable computer with the local database. 

38. The system of claim 28 wherein data is transmitted 
between the select input computer and the portable computer 65 
in an encoded format to reduce bits of information being 
transmitted. 
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39. The system of claim 28 wherein each input computer 
serves a local area and the select input computer is selected 
based on the respective local area and the position of the 
portable computer. 

40. A multi-tiered computing system comprising: 

a first computing tier having a master server computer, the 
master server coupled to a master database of master 
data records; 

a second computing tier having a plurality of input 
computers, each input computer coupled to a respective 
local database of local data records, each local database 
replicated from the master database; and 

a third computing tier having a remote portable computer, 
the portable computer being in communication with a 
select input computer for accessing local data records, 
the portable computer comprising: 
a CPU for controlling operation of the portable com- 
puter; 

an interface memory for storing software to control the 
CPU and to store temporarily at least one data set 
each data set having multiple data fields for storing 
data values; and 

a touch sensitive display screen for displaying at least 
a data I/O screen and for sensing contact by a user, 
the CPU defining multiple virtual regions upon the 
data I/O screen, each corresponding to a data field, 
the display screen sensing and informing the CPU of 
contact by the user within a virtual region, the 
display screen displaying within each virtual region 
a data value for the associated data field from a 
current data set for a current matter, the CPU iden- 
tifying a virtual region contacted by the user and 
effecting an interface control associated therewith, 
and wherein the display screen illustrates the current 
data set in at least one of a scroll bar format and a 
rolling key format. 

41. A multi-tiered computing system comprising: 

a first computing tier having a master server computer, the 
master server coupled to a master database of master 
data records; 

a second computing tier having a plurality of input 
computers, each input computer coupled to a respective 
local database of local data records, each local database 
replicated from the master database; and 

a third computing tier having a remote portable computer, 
the portable computer being in communication with a 
select input computer for accessing local data records, 
the portable computer comprising: 
a CPU for controlling operation of the portable com- 
puter; 

an interface memory for storing software to control the 
CPU and to store temporarily at least one data set 
each data set having multiple data fields for storing 
data values; and 

a touch sensitive display screen for displaying at least 
a data I/O screen and for sensing contact by a user, 
the CPU defining multiple virtual regions upon the 
data I/O screen, each corresponding to a data field, 
the display screen sensing and informing the CPU of 
contact by the user within a virtual region, the 
display screen displaying within each virtual region 
a data value for the associated data field from a 
current data set for a current matter, the CPU iden- 
tifying a virtual region contacted by the user and 
effecting an interface control associated therewith, 
and wherein each virtual region corresponds to a 
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predefined processing sequence which is initiated by 
the user by contacting the associated virtual region. 
42. A multi-tiered computing system comprising: 
a first computing tier having a master server computer, the 
master server coupled to a master database of master 5 
data records; 

a second computing tier having a plurality of input 
computers, each input computer coupled to a respective 
local database of local data records, each local database 
replicated from the master database; and 10 

a third computing tier having a remote portable computer, 
the portable computer being in communication with a 
select input computer for accessing local data records, 
the portable computer comprising: J5 
a CPU for controlling operation of the portable com- 
puter; 

an interface memory for storing software to control the 
CPU and to store temporarily at least one data set 



30 

each data set having multiple data fields for storing 
data values; and 
a touch sensitive display screen for displaying at least 
a data I/O screen and for sensing contact by a user, 
the CPU defining multiple virtual regions upon the 
data I/O screen, each corresponding to a data field, 
the display screen sensing and informing the CPU of 
contact by the user within a virtual region, the 
display screen displaying within each virtual region 
a data value for the associated data field from a 
current data set for a current matter, the CPU iden- 
tifying a virtual region contacted by the user and 
effecting an interface control associated therewith, 
and wherein the data I/O screen further displays 
multiple icons, each being uniquely associated with 
a data field. 

* * * * * 
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